fix: three live rig-package defects (#701, #702, #703) - #706

Fixes three reported rig-package defects. One of the three (#702) is refuted — the reported files are not broken, but the sweep it prompted found a different, real defect. Details below.

Found during the 2026-08-01 consolidation investigation (Extra-Chill/homeboy#11151).

#701 — stale rig-id env literal (CONFIRMED)

Automattic/studio/rigs/studio-agent-claude-trunk/rig.json declared:

"path": "${env.HOMEBOY_RIG_COMPONENT_PATH__STUDIO_AGENT_CLAUDE_EVALTIMING__STUDIO}"

while the rig id is studio-agent-claude-trunk. Homeboy derives the canonical override name from (rig_id, component_id) in rig_component_path_override_env_name (crates/homeboy-rig/src/expand.rs:241-247), so the variable that exists at runtime is ..._STUDIO_AGENT_CLAUDE_TRUNK__STUDIO. The rig was renamed from studio-agent-claude-evaltiming and the hand-written literal was never updated.

The literal was dead in both directions:

• when the canonical override is set, resolve_component_path returns it first and unconditionally (component_resolution.rs:34) — before path is consulted at all;
• when it is not set, ${env.…_EVALTIMING__STUDIO} expands to the empty string and resolution falls through to registry lookup.

Fix: deleted the literal rather than correcting it. path is optional (#[serde(default, skip_serializing_if)] on ComponentSpec) and the env override already applies unconditionally, so it was pure redundancy — and that redundancy is precisely what let the name drift undetected. No path_setting was present on this component. Behavior is unchanged in both cases.

#702 — Gutenberg imports (REFUTED — but the sweep found a real one)

The four reported Gutenberg workloads are not broken. WordPress/gutenberg/shared/wp-codebox is a symlink to ../../../shared/wp-codebox, tracked in git as mode 120000 (blob 13d7ff06). So ../shared/wp-codebox/recipe.mjs from WordPress/gutenberg/bench/ resolves through that symlink to the repo-root shared/wp-codebox/recipe.mjs, which exists.

Verified by actually importing all four under node: each runs its import graph to completion and fails only on its runtime env guard (HOMEBOY_COMPONENT_PATH is required), which proves the imports resolved. No change made to those four files.

Also worth noting the premise that "correct depth is three levels" is not universal — Automattic/studio/bench/lib/visual-fidelity.mjs correctly uses four (../../../../shared/...), because depth depends on the file's own location. Any future lint rule must resolve, not pattern-match.

The sweep did find one genuinely unresolvable import, unrelated to Gutenberg:

WordPress/wordpress-develop/tools/fuzz-workload-validator.mjs:1
  export { … } from './core-fuzz-contract-validator.mjs';   // target does not exist

That target was deleted by 8ce2060 ("Consolidate WordPress rigs on Codebox primitives", #684), which removed the implementation but left this one-line re-export shim behind. Nothing in the repo imports the shim — it is a dangling orphan whose entire content is an unresolvable specifier. Deleted, along with the now-empty tools/ directory.

#703 — duplicate lifecycle key (CONFIRMED)

woocommerce/woocommerce/rigs/woocommerce-performance/woocommerce-wp-codebox-target.base.json declared "lifecycle" twice (:2-7 and :65-69). serde_json is last-wins, so the second block silently overwrote the first and "intent": "external" was dropped from the materialized spec.

Merged into a single block at the original (first) position:

• intent: "external" restored. It is declared exactly once across both blocks, so there is no conflict on this field.
• reason taken from the second block. The two differ only in specificity ("component checkouts are user-owned" vs. "the WooCommerce component checkout is user-owned"). The second is the local refinement and is the string actually in effect on main today, so the human-readable text does not regress.

On the ambiguity

It is low, and here is the evidence rather than a guess: shared/wordpress-plugin/wp-codebox-external-cleanup.base.json contains the first block verbatim, so that block was copy-pasted from the shared external-cleanup base — and this file is itself named …-wp-codebox-target.base.json. external is the house pattern for exactly this kind of target. The only field that had to be adjudicated was reason, and there I kept the currently-effective string.

Runtime impact is nil, which is worth stating plainly so this is not mistaken for a behavior change in cleanup: RigCleanupSpec::resource_cleanup_intent maps both External and an absent intent to ResourceCleanupIntent::DryRun (crates/homeboy-rig/src/spec.rs), and RigCleanupIntent is not consumed anywhere else in homeboy. The dropped field was declarative/documentary. Restoring it makes declared cleanup ownership survive into the materialized spec without changing what cleanup does.

Why CI did not catch these

homeboy rig lint follows filenames rather than the materialized spec, and has no import resolution — tracked upstream as Extra-Chill/homeboy#11148. Demonstrated directly against origin/main with the defects still present:

• homeboy rig lint woocommerce/woocommerce --all → 0 failures with the duplicate lifecycle key in place. The "rig package JSON specs parse" step passes because serde_json accepts duplicates by design (last-wins); nothing compares the parsed spec against the source text.
• No lint step resolves .mjs import specifiers, so the orphaned shim was invisible.
• No lint step cross-checks a HOMEBOY_RIG_COMPONENT_PATH__… literal against the rig's own id, so the EVALTIMING/TRUNK drift was invisible.

Repo-wide sweeps

All three defect classes were swept exhaustively, not just the reported instances.

Follow-up worth considering (not changed here)

Every remaining "path": "${env.HOMEBOY_RIG_COMPONENT_PATH__<SELF>__<COMP>}" literal in the repo is self-consistent but equally redundant, for the same reason as #701: the override is applied unconditionally ahead of path, and absent the env var the literal expands to empty and falls through to registry lookup. They are correct today and are left alone, but they are the same drift hazard. Worth a follow-up to prune them, ideally alongside a lint rule from Extra-Chill/homeboy#11148.

Validation

• All 160 JSON files parse (python3 -m json.tool); duplicate-key sweep clean.
• All .mjs pass node --check; import sweep reports 0 broken.
• homeboy rig lint --all on woocommerce/woocommerce, WordPress/wordpress-develop, WordPress/gutenberg: 0 failures.
• Automattic/studio reports 1 failure (RigCleanupSpec untagged-enum schema skew) — pre-existing and identical on origin/main, verified by linting a clean origin/main extract with the same binary (v0.327.0). Not introduced here.
• No cargo invoked.